Possible duplicate or overlap with PR #2283

I'd like to merge the above mentioned PR, then rebase this PR against the current state.

@julmanglano
(Hopefully I didn't mess anything up for you with the rebase. 😮‍💨)

• I pulled your branch down, rebased it against our upstream state.
• Retained the existing second file of data (ends in number 2)
• Moved your new test data to a third file (ends in 3)
• The rebase required a force push because the commit hashes were different
• 📝 Note: Based on PR Add hp_procurve sh sys VSF stack support #2283, serial numbers are captured for each stack member

🎯 Please verify and test against a live device. Thank you!

Thanks @mjbear

Pulled the rebase and tested against my live 2-member VSF stack — the parse fails on real device output. System Contact wraps at column ~80 on HP procurve, and the orphan continuation hits ^. -> Error in the Start state, so the template is unusable against this device family as-is.

Anonymised example of the failing input:

  System Contact     : Network Operations Center (network-operations@example-long-domain.co
                       m)

A one-line swallow rule before ^. -> Error resolves it:

  ^\s{15,}\S

Verified locally — with the rule, the parse produces 2 records (one per VSF member), chassis-level Filldown values populate correctly across both, and per-member fields are distinct. Trade-off: contact (and location if it wraps too) is truncated to the first line.

Happy to push the fix to the branch — or you can apply it directly, whichever you prefer.

(The three committed fixtures still pass.)

System Contact wraps at column ~80 on HP procurve, and the orphan continuation hits ^. -> Error in the Start state, so the template is unusable against this device family as-is.

Oh darn

Anonymised example of the failing input:

  System Contact     : Network Operations Center (network-operations@example-long-domain.co
                       m)

Thank you for the visual example.

A one-line swallow rule before ^. -> Error resolves it:

  ^\s{15,}\S

It's fifteen spaces today, but that could change -- it may be worth using a leading \s+
Next, it appears there's not "trailing" white space after the wrapped system contact data.

Maybe change the data regex to a repeating pattern and anchor on the end of the line?
(and add a comment to remind us far into the future)

-  ^\s{15,}\S
+# match long sys contact that wraps to next line
+  ^\s+\S+$$

Agree, again, like I said before. I can push the fix to the branch, or feel free to apply it yourself — whichever works best for you.

@julmanglano
In your anonymized example, the line goes out to character 91.
Even though we'll anonymize, I would like the test data to be close to the real thing -- so what's the line length it wraps at?

Thanks @mjbear —

Wrap is at column 78 (2-char indent + 76 visible — standard 80-col terminal).

Tested a third stack while building the fixture and hit a case ^\s+\S+$$ doesn't catch. Anonymised, structure matches the real device:

example-switch# show system
...
  System Contact     : Network Operations Center (network-operations@example.c
                       om) location Building-3 Datacenter-Aisle-12 Rack-04 ABC
                       -ACCS1

Middle line has multiple tokens, so \S+$$ (one token to EOL) doesn't match. Relaxed to:

+# swallow wrap-continuation lines (long contact/location wrap at col 78)
+  ^\s+\S.*$$

Covers all three shapes I've seen — 1-, 2-, and 3-line wraps, single- or multi-token continuations. Specific field rules earlier in Start still take precedence so the swallow only fires on actual orphans.

Updated hp_procurve_show_system3 to cover the 3-line case. Captured value truncated to line 1, same trade-off as before.

Pushed.